The present invention relates generally to handling email flows, and more particularly to handling email flows arising from transactions initiated with a shared privileged identity at a service provider.
Organizations are increasing deploying privileged identity management (PIM) solutions for managing privileged identities in particular shared/functional IDs that are not tied to any specific user/employee. In a typical PIM scenario, the owner of the shared ID on-boards the ID's credentials into the PIM system and sets up a role for the ID such that only members of this role can have on-demand access to the credentials of the ID. To ensure accountability and traceability of actions performed with the shared ID at the target system, the PIM system enforces a check-out and check-in scheme so as to ensure that only one member of the role is using the ID at any time. So, if a user has checked out the ID from the PIM system and retrieved its latest password, no other member of the role can access the credentials until the user checks in the ID back into the PIM system, whereupon (if needed) the credentials will be rotated to a new value. In advanced PIM solutions, a user goes through a single sign-on (SSO) agent or gateway to check out a shared ID from the PIM system, and then gets auto-logged on to the target system with the checked-out credential; in this case, the user does not even see/know the credentials used.
A PIM system is traditionally used for managing shared access to privileged administrative IDs (e.g., root, administrator, and db2admin) on hosts (e.g., Windows, Linux, etc.), and databases (e.g., DB2, Oracle, etc.). However, the PIM system is increasingly being applied in the line-of-business domain for managing privileged shared access to various applications (usually web apps/sites) of business partners, vendors, suppliers, and other service providers. For example, the owner of the shared ID is the head of the procurement department, sets up an online account each with various suppliers for the purpose of initiating and managing purchases, and wants to allow a team of 5 procurement officers to use these online accounts to liaise with each of the suppliers. The business partners, suppliers, or vendors is a service provider; a customer wants to use a single shared online ID to connect to the service provider.
Many applications, particularly internet-based applications, uses e-mails as an essential way to conduct various workflows, such as secondary authentication, and/or to convey status updates (e.g., order status) and transactional data (e.g., new password) to users. For example, when ordering a virtual machine (VM) or a bare-metal server from an IaaS provider, the user have to wait for an email from the IaaS provider; in the email, the IaaS provider notifies the user of the provision of the VM or the server as well as the IP address and initial admin password of the VM or the server. In another example, when a purchase from an on-line store is initiated, emails are sent upon order confirmation, upon shipping from a warehouse, upon each stage of delivery, and upon final delivery of goods.
If an organization provisions individual IDs to a service provider, it can configure the ID's individual owner's email address with the ID for the service provider to send emails to. However, if an organization provisions a single shared ID to a service provider, then it is not clear whose email address should be configured for the application to send emails to. The shared ID is owned by a PIM user (e.g., a manager); however, since the ID can be used by any member of the corresponding PIM role, it is not clear whose email address should be configured for the service provider application to send emails to.
In a normal workaround, for each owner of a shared ID to request for a shared email address representing a distribution list that maps to multiple employees who are using the ID. However, it is challenging and a burden for both the ID's owner and the organization email administrator to track which user has entitlements to which shared ID in the PIM system and to keep the distribution list in sync with PIM's latest entitlements. This approach also leads to a proliferation of such shared email IDs in the organization's email system (as there will be one created per service provider), which will build-up over time and may stick around even after the ID/account with the service provider is defunct and removed from the PIM system.
Furthermore, if using a distribution list, employees will get spammed with emails not related to their interest. An employee cannot easily pick out what is relevant and of interest, and may end up missing emails that require attention. Emails may get sent to folks who did not use the ID recently. If the mailing list is not kept updated and in-sync with the role memberships in PIM system, the email may not be sent to the actual intended user but sent to employees who no longer belong to the role. In this situation, a PIM user will have to resort to periodically logging into the service provider site or application. This is a very unproductive exercise and adds unnecessary noise to the PIM system's check-in and check-out audit logs. Also, this leaves possibly sensitive email content (e.g., order information) inside user's individual mboxes.